2.2.  Abbreviated terms

ADES

Application Deployment and Execution Service

AP

Application Package

EMS

Exploitation Platform Management Service

3.1.  Enhancing Interoperability for Climate Resilience Information Systems

The OGC Climate Resilience Pilot will be the first phase of multiple long term climate activities aiming to evolve geospatial data, technologies, and other capabilities into valuable information for decision makers, scientists, policy makers, data providers, software developers, and service providers so we can make valuable, informed decisions to improve climate action. The goal is to help the location community develop more powerful visualization and communication tools to accurately address ongoing climate threats such as heat, drought, floods, fires as well as supporting the national determined contributions for greenhouse gas emission reduction. Climate resilience is often considered the use case of our lifetime, and the OGC community is uniquely positioned to accelerate solutions through collective problem solving with this initiative.

Figure 1

As illustrated, big, raw data from multiple sources requires further processing in order to be ready for analysis and climate change impact assessments. Applying data enhancement steps, such as bias adjustments, re-gridding, or calculation of climate indicators and essential variables, leads to “Decision Ready Indicators.” The spatial data infrastructures required for this integration should be designed with interoperable building blocks following FAIR data principles. Heterogeneous data from multiple sources can be enhanced, adjusted, refined, or quality controlled to provide Science Services data products for Climate Resilience. The OGC Climate Change Services Pilots will also illustrate the graphical exploration of the Decision Ready Climate Data. It will demonstrate how to design FAIR climate services information systems. The OGC Pilot demonstrators will illustrate the necessary tools and the visualisations to address climate actions moving towards climate resilience.

3.2.  The Role of the Pilot

The OGC Climate Resilience Community brings decision makers, scientists, policy makers, data providers, software developers, and service providers together. The goal is to enable everyone to take the relevant actions to address climate change and make well informed decisions for climate change adaptation. This includes scientists, decision makers, city managers, politicians, and last but not least, it includes everyone of us. So what do we need? We need data from lots of organizations, available at different scales for large and small areas to be integrated with scientific processes, analytical models, and simulation environments. We need data visualization and communication tools to shape the message in the right way for any client. Many challenges can be met through resources that adhere to FAIR principles. FAIR as in: Findable, Accessible, Interoperable, and Reusable. No single organization has all the data we need to understand the consequences of climate change. The OGC Climate Resilience Community identifies, discusses, and develops these resources. The OGC community builds the guidebooks and Best Practices, it experiments with new technologies to share data and information, and collaboratively addresses shared challenges.

The OGC Climate Resilience Community has a vision to support efforts on climate actions and enable international partnerships (SDG 17), and move towards global interoperable open digital infrastructures providing climate resilience information on users demand. This pilot will contribute to establishing an OGC climate resilience concept store for the community where all appropriate climate information to build climate resilience information systems as open infrastructures can be found in one place, be it Information about data services, tools, software, handbooks, or a place to discuss experiences and needs. The concept store covers all phases of Climate Resilience, from initial hazards identification and mapping to vulnerability and risk analysis to options assessments, prioritization, and planning, and ends with implementation planning and monitoring capabilities. These major challenges can only be met through the combined efforts of many OGC members across government, industry, and academia.

This Call for Participation solicits interests from organizations to join the upcoming Climate Resilience Pilot, an OGC Collaborative Solution and Innovation Program activity. This six-months Pilot is setting the stage for a series of follow up activities. It therefore focuses on use-case development, implementation, and exploration. It answers questions such as:

• What use-cases can be realized with the current data, services, analytical functions, and visualization capabilities that we have?

• How much effort is it to realize these use-cases?

• What is missing, or needs to be improved, in order to transfer the use-cases developed in the pilot to other areas?

3.3.  Objectives

The pilot has three objectives. First, to better understand what is currently possible with the available data and technology. Second, what additional data and technology needs to be developed in future to better meet the needs of the Climate Resilience Community; and third, to capture Best Practices, and to allow the Climate Community to copy and transform as many use-cases as possible to other locations or framework conditions.

3.4.  Background

With growing local communities, an increase in climate-driven disasters, and an increasing risk of future natural hazards, the demand for National Resilience Frameworks and Climate Resilience Information Systems (CRIS) cannot be overstated. Climate Resilience Information Systems (CRIS) are enabling data-search, -fetch, -fusion, -processing and -visualization. They enable access, understanding, and use of federal data, facilitate integration of federal and state data with local data, and serve as local information hubs for climate resilience knowledge sharing.

CRIS are already existing and operational, like the Copernicus Climate Change Service with the Climate Data Store. CRIS architectures can be further enhanced by providing climate scientific methods and visualization capabilities as climate building blocks. Based on FAIR principles, these building blocks enable in particular the reusability of Climate Resilience Information Systems features and capabilities. Reusability is an essential component when goals, expertises, and resources are aligned from the national to the local level. Framework conditions differ across the country, but building blocks enable as much reuse of existing Best Practices, tools, data, and services as possible.

Goals and objectives of decision makers vary at different scales. At the municipal level, municipal leaders and citizens directly face climate-related hazards. Aspects thus come into focus such as reducing vulnerability and risk, building resilience through local measures, or enhancing emergency response. At the state level, the municipal efforts can be coordinated and supported by providing funding and enacting relevant policies. The national, federal, or international level provides funding, science data, and international coordination to enable the best analysis and decisions at the lower scales.

Figure 2

Productivity and decision making are enhanced when climate building blocks are exchangeable across countries, organizations, or administrative levels (see Figure below). This OGC Climate Resilience Pilot is a contribution towards an open, multi-level infrastructure that integrates data spaces, open science, and local-to-international requirements and objectives. It contributes to the technology and governance stack that enables the integration of data including historical observations, real time sensing data, reanalyses, forecasts or future projections. It addresses data-to-decision pipelines, data analysis and representation, and bundles everything in climate resilience building blocks. These building blocks are complemented by Best Practices, guidelines, and cook-books that enable multi–stakeholder decision making for the good of society in a changing natural environment.

The OGC Innovation Program brings all groups together: The various members of the stakeholder group define use cases and requirements, the technologists and data providers experiment with new tools and data products in an agile development process. The scientific community provides results in appropriate formats and enables open science by providing applications that can be parameterized and executed on demand.

Figure 3

This OGC Climate Resilience Pilot is part of the OGC Climate Community Collaborative Solution and Innovation process, an open community process that uses the OGC as the governing body for collaborative activities among all members. A spiral approach is applied to connect technology enhancements, new data products, and scientific research with community needs and framework conditions at different scales. The spiral approach defines real world use cases, identifies gaps, produces new technology and data, and tests these against the real world use cases before entering the next iteration. Evaluation and validation cycles alternate and continuously define new work tasks. These tasks include documentation and toolbox descriptions on the consumer side, and data and service offerings, interoperability, and system architecture developments on the producer side. It is emphasized that research and development is not constrained to the data provider or infrastructure side. Many tasks need to be executed on the data consumer side in parallel and then merged with advancements on the provider side in regular intervals.

Good experiences have been made using OGC API standards in the past. For example, the remote operations on climate simulations (roocs) use OGC API Processes for subsetting data sets to reduce the data volume being transported. Other systems use OGC STAC for metadata and data handling or OGC Earth Observation Exploitation Platform Best Practices for the deployment of climate building blocks or applications into CRIS architectures. Still data handling regarding higher complex climate impact assessments within FAIR and open infrastructures needs to be enhanced. There is no international recommendation or best practice on usage of existing API standards within individual CRIS. It is the goal of this pilot to contribute to the development of such a recommendation, respecting existing operational CRIS that are serving heterogen user groups

Figure 4

.

3.5.  Technical Challenges

Realizing the delivery of Decision Ready Data on demand to achieve Climate Resilience involves a number of technical challenges that have already been identified by the community. A subset will be selected and embedded in use-cases that will be defined jointly by Pilot Sponsors and the OGC team. The goal is to ensure a clear value-enhancement pipeline as illustrated in Figure 1, above. This includes, among other elements, a baseline of standardised operators for data reduction and analytics. These need to fit into an overall workflow that provides translation services between upstream model data and downstream output — basically from raw data, to analysis-ready data, to decision-ready data. The following technical challenges have been identified and will be treated in the focus areas cycles of the Pilot accordingly:

• Big Data Challenge: Multiple obstacles still exist, creating big barriers for seamless information delivery starting from Data Discovery. Here the emergence of new data platforms, new processing functionalities, and thus new products, data discovery remains a challenge. In addition to existing solutions based on established metadata profiles and catalog services, new technologies such as OGC’s Spatio-Temporal Asset Catalog (STAC) and open Web APIs such as OGC API Records will be explored. Furthermore, aspects of Data Access need to be solved where the new OGC API suite of Web APIs for data access, subsetting, and processing are currently utilized very successfully in several domains. Several code sprints have shown that server-side solutions can be realized within days and clients can interact very quickly with these server endpoints, thus development time is radically reduced. A promising specialized candidate for climate data and non-climate data integration has been recently published in the form of the OGC API — Environmental Data Retrieval (EDR). But which additional APIs are needed for climate data? Is the current set of OGC APIs sufficiently qualified to support the data enhancement pipeline illustrated in Figure 1? If not, what modifications and extensions need to be made available? How do OGC APIs cooperate with existing technologies such as THREDDS and OPEnDAP? For challenges of data spaces, Data Cubes have recently been explored in the OGC data cube workshop. Ad hoc creation and embedded processing functions have been identified as essential ingredients for efficient data exploration and exchange. Is it possible to transfer these concepts to all stages of the processing pipeline? How to scale both ways from local, ad hoc cubes to pan-continental cubes and vice versa. How to extend cubes as part of data fusion and data integration processes?

• Cross-Discipline Data Integration: Different disciplines such as Earth Observation, various social science, or climate modeling use different conceptual models in their data collection, production, and analytical processes. How can we map between these different models? What patterns have been used to transform conceptual models to logical models, and eventually physical models? The production of modern Decision-ready information needs the integration of several data sets, including census and demographics, further social science data, transportation infrastructure, hydrography, land use, topography and other data sets. This pilot cycle uses ‘location’ as the common denominator between these diverse data sets and works with several data providers and scientific disciplines. In terms of Data Exchange Formats the challenge is to know what data formats need to be supported at the various interfaces of the processing pipeline? What is the minimum constellation of required formats to cover the majority of use cases? What role do container formats play? Challenging on technical level is also the Data Provenance. Many archives include data from several production cycles, such as IPCC AR 5 and AR 6 models. In this context, long term support needs to be realized and full traceability from high level data products back to the original raw data. Especially in context of reliable data based policy, clear audit trails and accountability for the data to information evolution needs to be ensured.

• Building Blocks for processing pipelines: With a focus on Machine Learning and Artificial Intelligence which plays an increasing role in the context of data science and data integration. This focus area needs to evaluate the applicability of machine learning models in the context of the value-enhancing processing pipeline. What information needs to be provided to describe machine learning models and corresponding training data sufficiently to ensure proper usage at various steps of the pipeline? Upcoming options to deploy ML/AI within processing APIs to enhance climate services are rising challenges e.g. on how to initiate or ingest training models and the appropriate learning extensions for the production phase of ML/AI. Heterogeneity in data spaces can be bridged with Linked Data and Data Semantics. Proper and common use of shared semantics is essential to guarantee solid value-enhancement processes. At the same time, resolvable links to procedures, sampling & data process protocols, and used applications will ensure transparency and traceability of decisions and actions based on data products. What level is currently supported? What infrastructure is required to support shared semantics? What governance mechanisms need to be put in place?

3.6.  How is this Pilot Relevant to the Climate Resilience Domain Working Group?

The Climate Resilience DWG will concern itself with technology and technology policy issues, focusing on geospatial information and technology interests as related to climate mitigation and adaptation as well as the means by which those issues can be appropriately factored into the OGC standards development process.

The mission of the Climate Resilience DWG is to identify geospatial interoperability issues and challenges that impede climate action, then examine ways in which those challenges can be met through application of existing OGC Standards, or through development of new geospatial interoperability standards under the auspices of OGC.

Activities to be undertaken by the Climate Resilience DWG include but are not limited to:

• Identify the OGC interface standards and encodings useful to apply FAIR concepts to climate change services platforms;

• Liaise with other OGC Working Groups (WGs) to drive standards evolution;

• Promote the usage of the aforementioned standards with climate change service providers and policy makers addressing international regional and local needs;

• Liaise with external groups working on technologies relevant to establishing ecosystems of EO Exploitation Platforms;

• Liaise with external groups working on relevant technologies;

• Publish OGC Technical Papers, Discussion Papers or Best Practices on interoperable interfaces for climate change services;

• Provide software toolkits to facilitate the deployment of climate change services platforms.

4.1.  ECMWF — Copernicus

• Component: Copernicus services.

• Outputs: Copernicus Services, including Climate Data Store (CDS) https://cds.climate.copernicus.eu/ and Atmosphere Data Store (ADS) https://ads.atmosphere.copernicus.eu/.

• What other component(s) can interact with the component: CDS and ADS provide access to data via different interfaces: UI and API. It also offers a toolbox with a set of expert libraries to perform advanced operations on the available data. CDS and ADS catalogue metadata is also accessible via standard CSW. https://cds.climate.copernicus.eu/geonetwork/srv/eng/csw?SERVICE=CSW=2.0.2=GetCapabilities

• What OGC standards or formats does the component use and produce:

  • CDS and ADS catalogues exposed via CSW.

  • Access to ESGF datasets via WPS.

  • WMS is offered in some published applications.

  • CADS 2.0 (under construction) will implement OGC APIs.

4.2.  Pixalytics

Pixalytics are developing an OGC-compliant API service, see Figure 6, which will provide global information on droughts. The approach is to take global open data/datasets from organizations such as ESA/Copernicus, NASA/NOAA and the WMO and combine meteorology, hydrology, and remote sensing data to produce ARD data based on a composite of different indicators. Where globally calculated drought indicators already exist, these are being used in preference to their re-calculation, although consistency and the presence of uncertainties are also being considered.

Figure 6 — Pixalytics architecture

Currently, the Standardized Precipitation Index (SPI) is being calculated using ERA5 reanalysis data from the Copernicus Climate Change Service. The API access is being set up following the Building Blocks for Climate Services (https://climateintelligence.github.io/smartduck-docs/) approach. Once all steps are working for SPI, the next step is adding soil moisture and vegetation drought indices. Also, work on how to combine indices into a single view/indicator is being considered.

• Component: Drought indicator.

• Inputs: Meteorological data, including Precipitation, plus Land Surface Temperature, Soil Moisture, Vegetation Index (or optical data to calculate it from).

• Outputs: Drought Indices — as a time-series dataset output in JSON or COG format.

• What other component(s) can interact with the component: a desire to link to visualization/DRI analysis components. A QGIS plugin has been updated to be able to perform a request and view the outputted JSON file (https://github.com/pixalytics-ltd/qgis-wps-plugin) and the WPS link is https://api.pixalytics.com/climate/wps?request=GetCapabilities=wps (under testing/improvement for robustness).

• What OGC standards or formats does the component use and produce: Producing data on-the-fly using the Web Processing Service (WPS), so need to pull data through preferably an API route.

4.3.  Wuhan University (WHU)

Wuhan University (WHU) is a university that plays a significant role in researching and teaching all aspects of surveying and mapping, remote sensing, photogrammetry, and geospatial information sciences in China. In this Climate Resilience Pilot, we will contribute two use-cases: a use-case for drought and wildfire impact, and a use-case for analysis ready data.

• Component: Data Cube and Drought Indicator.

• Inputs: Climate data, including precipitation and temperature. Optical data, such as Landsat-8 and sentinel-2.

• Outputs: Drought risk map and other results in the form of GeoTIFF after processing in a Data Cube.

• What other component(s) can interact with the component: .

• What OGC standards or formats does the component use and produce:

  • OGC API — Coverages to provide the data in Cube

  • OGC API — Processes to provide the calculation of drought indices

4.4.  Ecere Corporation

Ecere is providing a deployment of its GNOSIS Map Server with a focus on a Sentinel-2 Level 2A data cube. OGC API - Tiles, OGC API - Coverages, OGC API - Maps, OGC API — Discrete Global Grid Systems, Common Query Language (CQL2), and OGC API — Processes — Part 3: Workflows & Chaining are the supported standards and extensions for this task.

Plan to use the process output to identify vegetation fuel type, then combine with weather data to assess wildfire hazards risk in Australia.

• Component: Data Cube and Wildfire vegetation fuel map / risk analysis.

• Inputs: ESA Sentinel-2 L2A data (from AWS / Element 84), Temperature / Precipitation / Wind climate data, Reference data for training: vegetation fuel type classification, wildfire risk.

• Outputs: OGC API (Coverage, Tiles, DGGS, Maps) for Sentinel-2 data (https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a) including full global coverage, all resolutions/scales, all bands that can be individually selected, CQL2 expressions for band arithmetics; climate data (to be added), vegetation fuel type (possibly by end of pilot, or for DP2023), wildfire risk workflow (possibly by end of pilot, or for DP2023).

• What other component(s) can interact with the component: Any OGC API client component requiring efficient access to Sentinel-2 data, clients requiring climate data once made available, clients presenting vegetation fuel type, wildfire risk (once ready, might extend into DP2023).

• What OGC standards or formats does the component use and produce:

  • OGC API (Coverage — with subsetting, scaling, range subsetting, coverage tiles; Tiles, DGGS (GNOSISGlobalGrid and ISEA9R), Maps (incl. map tiles), Styles), CQL2, OGC API — Processes with Part 3 for workflows (Nested Local/Remote Processes, Local/Remote Collection Input, Collection Output, Input/Output Field Modifiers)

  • Formats: GNOSIS Map Tiles (Gridded Coverage, Vector Features, Map imagery, and more); GeoTIFF; PNG (16-bit value single channel for coverage, RGBA for maps); JPEG.

4.5.  Jakub P. Walawender

• Component: Solar climate atlas for Poland.

• Inputs: In situ solar radiation and sunshine duration data, satellite-based solar radiation and sunshine duration estimates (climate data records), various different geospoatial data from different sources (e.g. digital elevation model, climate zones, etc.).

• Outputs:

  • This pilot outputs: Review of available solar radiation datasets and web services, 2 scripts (solar climate data exploratory analysis tool, solar climate data preprocessing tool), report summarizing results of the exploratory data analysis and quality control including discussion of inconsistency factors.

  • In the final result: solar radiation data cube for Poland (40 years of high resolution dataset for selected solar radiation variables), and analysis ready data (dedicated products for different solar-smart applications in the fields of renewable energy, agriculture, spatial planning, tourism, etc.), detailed analysis of the solar climate in Poland (incl. solar regionalisation) and online web map service with an interactive, self-explainable interface enabling easy on-demand information access.

• What other component(s) can interact with the component: This component work (considering the final result) crosses all the components and all of them are actually important.

• What OGC standards or formats does the component use and produce:

  • NetCDF compliant with the CF (Climate and Forecast) convention.

  • WMS, WCS, OGC API

4.6.  Safe Software

• Component:

  • Climate ARD component — Data Cube to ARD.

  • Impact Components general I/O (Heat, Drought, Flood).

• Inputs:

  • Climate ARD component — Data Cube to ARD: Climate scenario data from climate services (NetCDF), for historic and future time periods

  • Impact Components general I/O (Heat, Drought, Flood): Climate impact ARD from Safes ARD component, including EO data (MODIS, LANDSAT, SENTINEL products), Population/Infrastructure information (OSM), Basemaps, as well as specific requirements per impact:

  • Drought: vegetation, soils, hydrology, basins

  • Flood: DEM, hydrology, basins.

• Outputs:

  • Climate ARD component — Data Cube to ARD: Gridded data, including temperature, soil moisture and precipitation — aggregate grids (GeoTIFF/COG), as well as Vector data, including temperature, soil moisture and precipitation contours (Geopackage, GeoJSON, OGC API Features).

  • Impact Components general I/O (Heat, Drought, Flood): Risk Contours (Geopackage, GeoJSON, OGC API Features).

• What other component(s) can interact with the component: Pixalytics Component: consume variables for Drought Indicator produced by Safe’s ARD component. Any other component that requires climate scenario summary ARD to drive DRI.

• What OGC standards or formats does the component use and produce:

  • OGC API Features

  • Geopackage

  • NetCDF

  • GeoJSON

  • GeoTIFF/COG

  • As needed: GML, KML, PostGIS, geodatabase and about 400 other geospatial formats.

Figure 7 — High level FME ARD workflow showing generation of climate scenario ARD and impacts from climate model, EO, IoT, infrastructure and base map inputs

4.7.  GMU_CSISS

• Component: Analysis Ready Data (ARD).

• Inputs: ECV record information, OpenSearch service endpoint (currently CMR(CWIC) and FedEO), download URLs for accessing NetCDF or HDF files.

• Outputs: WCS service endpoint for accessing selected granule level product images (GeoTIFF, PNG, JPEG, etc.).

• What other component(s) can interact with the component: .

• What OGC standards or formats does the component use and produce:

  • WCS for downloading image

  • WMS for showing layers on basemap

4.8.  AlpS

• Component: climate Communication and support for adaptation.

• Inputs: Selected climate indicators (past and future, different scenarios), cartographic data (hazard zones, HQ areas, etc.), existing plans, strategies and concepts (regional development plans, climate protection strategies, previous analyses).

• Outputs: Target group-specific communication material (factsheets, graphs), description of the vulnerability and visualization of risk maps, adaptation measures, strategies for adaptation to climate change. In the context of this pilot alpS will elaborate a guideline that helps to find a proper workshop-setup. alpS will illustrate the guideline with two to three best practice examples. As far as possible, alpS will test its findings in ongoing consultancies.

• What other component(s) can interact with the component: .

• What OGC standards or formats does the component use and produce: .

4.9.  Laubwerk

Laubwerk is a private company working on building a large database of vegetation that includes fully detailed 3D models as well as metadata to represent its properties.

• Component: Visualization of an example tile of Los Angeles with full vegetation coverage and using our plant metadata to compute and visualize different climate scenarios and mitigation measures.

• Inputs:

  • Laubwerk plant database for 3D models and plant metadata

  • Los Angeles — Bureau of Street Services — Tree Inventory (https://streetsla.lacity.org/tree-inventory)

• Outputs:

  • Imagery of the different projected scenarios

4.10.  RSS-Hydro

RSS-Hydro has been part of several successful OGC testbeds, including the DP 21 to which this pilot is linked, not only in terms of ARD and IRD but also in terms of use cases. In this pilot, RSS-Hydro’s main technical contribution will be creating digestible OGC data types and formats for specific partner use cases, so the contribution will be focusing on producing ARD from publically available EO and model data, including hydrological model output as well as climate projections. These ARD will feed into all use cases for all participants, with a particular focus toward the use cases proposed for Heat, Drought and Health Impacts by other participants in the pilot.

Specifically, RSS-Hydro can provide access to the following satellite and climate projection data: * Wildfire – Fire Radiant Power (FRP) product from Sentinel 3 (NetCDF), 5p, MODIS products (fire detection), VIIRS (NOAA); possibly biomass availability (fire fuel). * Land Surface Temp — Sentinel 3 * Pollution — Sentinel 5p * Climate Projection data (NetCDF, etc., daily downscaled possible): air temp (10 m above ground). Rainfall and possibly wind direction as well * Satellite-derived Discharge Data to look at Droughts/Floods etc. by basin or other scale * Can provide some hydrological model simulation outputs at (sub)basin scale (within reason)

The created ARD in various OGC interoperable formats will create digestible dataflows for the proposed OGC Use Cases. This proposed data chain by RSS-Hydro is similar to DP21. The created climate and hydrological basin model outputs (NetCDF etc.) or EO remote sensed data (NASA, NOAA, ESA, etc.) from among other sources the Global Flood Observatory (DFO) and RSS-Hydro can be simplified to GeoTIFF and / or vectorized geopackage per time step by the FME software. Another option as an intermediate data type (IRD) would be COG — cloud optimized geotiff which would make access more efficient. The COG GeoTIFFs are optimized for cloud so we could make sure we have a cloud based storage bucket to make the data sharing more efficient. ARD and IRD should become more service / cloud based wherever possible.

Besides the data format we need to think more about data structures and semantics required to support the desired DRI’s. The time series / raster, and classification to vector contour transform is an approach that worked well in DP21 and may be a good starting point here. For example, together in the FME processing engine, we can take time series grids, aggregate them across timesteps to perhaps mean or max values, then classify them into ranges suitable for decision making, and then write them out and expose them as time tagged vector contour tables.

In summary, the different ARD and IRD data can be created from the following data sources: * Inputs: EO (US sources fire related: MODIS, VIIRS); Climate projections, sub catchment polygons, assisting Albert with EO Europe sources; Sentinel-3, Sentinel 5-P * Outputs forma & instances: WCS, GeoTIFF spatial / temporal subset, Shape; NetCDF * Output parameters: e.g. hydrological condition of a basin (historically/current). So drought / flood etc. * Output themes: downscaled / subset outputs, hydrologic scenarios

4.11.  Component workflow

The figure below shows a high level workflow diagram that illustrates the interactions between data, models and the various components.

Figure 8 — High level workflow diagram that illustrates the interactions between data, models and the various components

5.1.  Drought and Wildfire Impact Use-case

Drought and wildfire caused by climate change are one of the important factors affecting agricultural production, food security, and water shortage. The goal of WHU is to develop a use-case for drought and wildfire risk assessment for rapid response to drought and wildfire occurrences. Figure 1 shows the technical architecture on how WHU contributed to the use-case. It has the following features: 1) For data discovery, a catalogue service from data center following OGC API is provided allowing users to search geospatial data both available from WHU data stores and remote data stores from USGS, ESA, and NASA. 2) For data integration, data can be integrated into the WHU software in the form of geo date cubes with three efforts: formalizing cube dimensions for multi-source geospatial data, processing geospatial data query along cube dimensions, and organizing cube data for high-performance geoprocessing. 3) For data processing, a processing chain is enabled in WHU software using a code editor and modelbuilder. 4) For data visualization, a Web-based client for visualization of spatial data and statistics is provided using a virtual globe and charts.

Figure 9 — The technical architecture of the use-case for drought and wildfire impact

Figure 2 a is the data center of the proposed use-case, which currently stores multiple sources data from different platforms including 20 years of precipitation data from GPM (Global Precipitation Measurement) used to calculate the drought index. The drought and wildfire risk assessment algorithms are integrated in the algorithm center, which can be invoked by the code editor or modelbuilder to perform drought and wildfire risk assessment. Figure 2b shows the Python code and visualization result of the drought risk assessment in Asia based on precipitation anomaly percentage (PAP) index.

Figure 10 — An example of the drought risk assessment in parts of Asia.

5.2.  Analysis Ready Data Use-case

The technical design on how WHU contributed to the ARD use-case encompasses the query, download, and pre-processing of multi-source EO data. The query and download operators collect open EO data from open EO providers (USGS, ESA, and NASA). In addition to EO datasets, we also provide meteorological datasets including ECMWF climate reanalysis and MODIS atmospheric products. The pre-processing workflows create ARD for both optical and SAR imagery. Moreover, for applications that need spectral and angular harmonization, the pre-processing workflow supports the harmonization of multi-source optical imagery. Figure 1 shows the processing chain to produce harmonized ARD. The harmonization involves spatial co-registration, band conversion, and bidirectional reflectance distribution function (BRDF) correction.

Figure 11 — The processing chain to produce harmonized ARD

To demonstrate our ability to produce ARD and promote the use of Chinese satellite data, we will produce a surface reflectance ARD dataset through the harmonization of Gaofen-1 WFV (Wide Field of View), Gaofen-6 WFV, and Sentinel-2 data. Figure 2 shows the Sentinel-2 data before and after pre-processing. Besides, we’d like to coordinate with the ARD SWG to promote standards for ARD and ensure that the ARD we produce is stable and reusable. Furthermore, we wish to seek the assessment of CEOS-ARD in our long-term plan.

Figure 12 — Sentinel-2 RBG composite (red Band4, green Band3, blue Band2), over Hubei, acquired on October 22, 2020. (a) corresponds to the reflectance at the top of the atmosphere (L1C product), (b) corresponds to the surface reflectance after pre-processing.

5.3.  Analysis Ready Data (ARD) Use Case (D-100 Client instance by George Mason University)

Analysis Ready Data (ARD) is remote sensing data and products that have been pre-processed and organized to allow immediate analysis with little additional user effort and interoperability both through time and with other datasets.

5.3.2.  Approach

The client instance is implemented as a Web application to support the creation and delivery of ARD for climate change impact assessment.

The Carbon Portal conducted data discovery and access in two steps:

• step 1: Data collection search

• step 2: Granule search to search granules in the collection

ARD services are enabled on results of granule search if the collection is an ECV. If the ECV data provider has implemented the WCS service for the dataset, the portal will directly communicate with ECV provider’s WCS server for ARD service. If the ECV data provider does not have the WCS service, the portal’s server will download entire granule and stage it on the portal server to provide ARD service.

Most of ECV data provides don’t provide such service.

The following figure is a software architecture of the CEOS WGISS Carbon Community Portal.

Figure 13 — Software Architecture

ECV Inventory v4.1 records are converted as a unified form of the portal predefined metadata format by a converting tool. Retrieve collection metadata for ECV entries from CWIC/FedEO OpenSearch referred by Data Record Information. There is 1251 ECV inventory records (Same as WGClimate, 870 for Existing, 381 for Planned). The portal supports totally 1910 predefined ECV relative collection datasets from ECV Records.

ARD service for ECVs in case that providers have no WCS services:

• Support when user select one granule entry

• Download granule dataset file from given repository, and manipulate it for serving WCS

• Stage the data in portal backend server and generate a list of all coverages in the granule

• User specifies the specifications of data to download

• User obtains the customized data by downloading via WCS GetCoverage request

ARD service for ECVs with data providers’ WCS:

• Directly talk to provider’s WCS

• Without granule downloading and stage steps in the portal’s backend server.

5.3.3.  Use Case: The climate change impact on crop production in Turkmenistan

The use case of the climate change impact on crop production in Turkmenistan. However, the portal can switch to another use case or support multiple use cases if this pilot requests us to do so.

Drought is one of the major climate-related natural hazards that cause significant crop production loss in Turkmenistan. Climate change increases the risk of drought in Turkmenistan. Crop models (such as WOFOST) are often used to support the decision-making in long-term adaptation and mitigation. The client will be used to prepare data to be readily used as parameters and drivers in such modeling processes. Drought impact analysis data may include long time series of precipitation, temperature, or indices for crop conditions, water content, or evapotranspiration. Many of these climate data and products from satellite sensors are served at NASA’s Goddard Earth Sciences Data and Information Services Center, such as GPM data products, MERRA assimilated climate data. These will be used in the case of drought impact assessment in Turkmenistan.

The drought impact ARD case will demonstrate:

1. Applicability of open standards and specifications in support of data discovery, data integration, data transformation, data processing, data dissemination and data visualization

2. Transparency of metadata, data quality and provenance

3. Efficiency of using ARD in modeling and analysis

4. Interoperable dissemination of ARD abiding by FAIR principles

The searching is starting with the following information:

• Keyword: surface soil moisture

• Filter: daily

• Date: 10/1/2021, 10/1/2020, 10/1/2019, 10/1/2018

• Area: Turkmenistan (Bbox: 52.264(Left), 35.129(Bottom), 66.69(Right), 42.8(Top))

Choose a collection dataset:

Groundwater and Soil Moisture Conditions from GRACE and GRACE-FO Data Assimilation L4 7-days 0.25 x 0.25 degree Global V3.0 (GRACEDADM_CLSM025GL_7D) at GES DISC

Choose the following granule data file:

GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20220926.030.nc4 (for year 2022)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20210927.030.nc4 (for year 2021)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20200928.030.nc4 (for year 2020)
GRACEDADM_CLSM025GL_7D.3.0:GRACEDADM_CLSM025GL_7D.A20190930.030.nc4 (for year 2019)

Retreve the file and choose a variable:

sfsm_inst (Surface soil moisture percentile)

Adjust legend color (0 is the least soil moisture), and get the following results:

Figure 14 — Surface soil moisture percentile (year 2019-2022)

5.4.  Solar climate atlas for Poland — Climate Resilience Information System

Jakub P. Walawender (Freelance climate scientist and EO/GIS expert) email:contact@jakubwalawender.eu

The project aims at updating previously created solar climate atlas for Poland by:

• increasing spatial and temporal resolution of the datasets;

• extending time span

• replacing static maps with a dynamic and interactive interface;

• using practical solar radiation parameters instead of physical variables;

• making datasets (+ metadata) available for downloaded in interoperable file formats for further use

• sharing a solar climate knowledge base and data/service user guide

in order to:

• advance development of the solar-smart society and economy in PL

• provide know-how and tools, which are easily reusable in other geographical regions

Figure 15 — Solar Climate atlas for Poland available on the IMGW website: https://klimat.imgw.pl/en/solar-atlas

Newly created solar climate data cube and web map service will be more FAIR as they will be made available online, possibly on the official website of the Polish Hydrometeorological Service (IMGW) for an increased findability, upon future agreement (to be discussed) to make them more Findable by the general public. The whole process of data access (including authentication) will be transparent and accompanied by appropriate instructions so that the Accessibility could be much higher. The format of the datasets in the data cube will be an OGC netCDF standard compliant with the CF (Climate and Forecast) convention, which is suitable for encoding gridded data for space/time-varying phenomena and commonly known in the climate science community but also easily readable with other common spatial data processing and visualization software including most of the GIS software to keep fully Interoperable. Finally, even though the proposed solar climate information system (maps+ dataset) are limited to the area of Poland, all processing scripts will be made available on github along with a well-described processing steps (both Jupyter notebooks and instructional videos will be considered) to provide Reusability for other countries or geographical regions.

Two objectives for the pilot OGC Climate Resilience Pilot are:

• to document existing solar radiation datasets (satellite, model and reanalysis data) and services (both freely accessible and commercial)

• to verify the accuracy of the in situ measurements and satellite climate data records for the selected solar radiation parameters using proper statistical methods